Method and system for parsing purchase information from web pages

ABSTRACT

A method for parsing purchase information from code in a Web page. The method includes detecting at least one known product keyword and at least one product data string following that product keyword and being associated with that product keyword. The product data string can be a descriptor for the product keyword for one product in the purchase. The method also includes detecting at least one known transaction keyword and at least one transaction data string following that transaction keyword and being associated with that transaction keyword, the transaction data string being a descriptor for the transaction keyword. The data type of the descriptors can be checked to determine if they are of the same type as the corresponding product or transaction keyword. These processes can be repeated for all of the data strings in the HTML page, and this detected purchase information can be placed into an organized form.

FIELD

The present invention relates generally to methods and systems forparsing purchase information from a Web page without the need forspecific knowledge about the structure of the Web page.

BACKGROUND

Applications that require or benefit from the capture of purchaseinformation from Web pages have been developed in a number of areas.Some applications, for instance, aggregate purchase information from anumber of different Web sites for a given consumer. Other applicationsgather purchase information from a given consumer's purchases over theInternet in order to build a profile of the consumer, which can be usedfor targeted advertising based on the user's profile.

The accuracy of information parsed from Web pages can be important inorder to provide useful information about the consumer. Some methods andsystems for parsing purchase information that are currently used arespecifically tailored for each Web site from which purchase informationwill be parsed. These parsing systems and methods, therefore, will havea number of templates for parsing Web pages, with each template beingdesigned for one specific Web page. This results in problems if the Website to be parsed changes or if it is desired to use the method forother Web sites. In addition, it is common for parsing systems andmethods to identify these Web pages to be parsed by specific UniformResource Locator (URL) information. A URL identifies a network path to aspecific Web site. If this URL information changes, these parsingsystems and methods might not work.

A need exists for a method and system for parsing purchase informationfrom a Web page without the need for specific knowledge about thestructure of the Web page.

SUMMARY

The present invention is directed to a method and system for parsingpurchase information from a Web page. This purchase information caninclude product information, such as the product name, description, andprice, as well as transaction information, which can include anyinformation about the total purchase, such as the credit card used forthe purchase, the total cost of all products purchased, and the type ofshipping selected. In one embodiment, the system includes a sniffer todetect Web pages with purchase information and a parser to parse thepurchase information from the HTML Web pages. The parser can containinstructions for parsing according to the method described below forparsing.

In one embodiment, the method includes detecting at least one knownproduct keyword and at least one product data string following thatproduct keyword and being associated with that product keyword. Theproduct data string can be a descriptor for the product keyword for oneproduct in the purchase. The method also includes detecting at Least oneknown transaction keyword and at least one transaction data stringfollowing that transaction keyword and being associated with thattransaction keyword, the transaction data string being a descriptor forthe transaction keyword. The data type of the descriptors can be checkedto determine if they are of the same type as the corresponding productor transaction keyword. These processes can be repeated for all of thedata strings in the HTML page, and this detected purchase informationcan be placed into an organized form. Another aspect of the inventioncan include a computer readable medium incorporating instructions toperform this method.

Purchase information can be parsed from, for example, confirmation andcheckout pages from on-line shopping Web sites. In one embodiment, themethod and system parse purchase information from Web pages in a waythat does not require specific knowledge of the Web site, such as thetemplates used by the Web pages, and in a way that is impervious tochanges in the structure or content of the Web site.

BRIEF DESCRIPTION OF THE DRAWINGS

For a fuller understanding of the nature and objects of the presentinvention, reference should be made to the following detaileddescription taken in connection with the accompanying drawings wherein:

FIG. 1 is a block diagram illustrating a representative network in whichthe inventive system may be implemented.

FIG. 2 is a block diagram of a flow chart of one embodiment for parsingpurchase information.

FIG. 3 is list of product keywords that can be used in one embodiment.

FIG. 4 is list of transaction keywords that can be used in oneembodiment.

DETAILED DESCRIPTION

The present invention is directed to a method and system for parsingpurchase information from a Web page. Such purchase information can beparsed from, for example, confirmation and checkout pages from on-lineshopping Web sites. In one embodiment, the method and system parsepurchase information from Web pages in a way that does not requirespecific knowledge of the Web site, such as the templates used by theWeb pages, and in a way that is impervious to changes in the structureor content of the Web site. The system and method described herein dothis by taking into account the structure of purchase information, thelimited number of English words used to describe purchases, and thestructure of HTML Web pages.

The purchase information that is parsed from Web pages can be used in avariety of ways. In one embodiment, the parsed information can be usedto develop a profile of a computer user. For example, if parsedinformation indicates that a client buys a large number of books,relevant information can be added to the user's profile indicating anaffinity for books and literature. Targeted advertising could then beused to advertise literature or books to that user. It should be noted,however, that the present invention is not limited to the building ofsuch profiles. Instead, the method and system for parsing purchaseinformation can be used to gather purchase information that can be usedin a variety of ways.

FIG. 1 illustrates a representative network in which the inventivesystem may be implemented in one embodiment. The network includes one ormore client machines 10 operated by various individual users. The clientmachines 10 connect to multiple servers 12 via a communication channel14, which can be the Internet. It may, however, alternatively be anIntranet or other connection. In the case of the Internet, the servers12 are Web servers that are selectively accessible by various clients.The Web servers 12 operate so-called “Web sites” and support files inthe form of documents and pages. A network path to a Web site generatedby the server is identified by a Uniform Resource Locator (URL).

One example of a client machine 10 is a personal computer such as aPentium-based desktop or notebook computer running the Windows operatingsystem. A representative computer includes a computer processing unit,memory, a keyboard, a mouse and a display unit. The screen of thedisplay unit is used to present a graphical user interface (GUI) for theuser. The GUI is supported by the operating system and allows the userto use a point and click method of input, e.g., by moving the mousepointer on the display screen and pressing on the mouse buttons toperform a user command or selection. Also, one or more “windows” may beopened up on the screen independently or concurrently as desired. Thecontent delivered by the system to users is displayed on the screen.Other types of client devices are also possible such as mobile Internetdevices (e.g., Web-connected cellular phones and personal digitalassistants).

Client machines 10 typically include browsers, which are known softwaretools used to access the servers 12 of the network. Representativebrowsers include Netscape Navigator and Microsoft Internet Explorer,although other browsers may be used within the scope of the embodimentsdescribed herein. Client machines 10 usually access servers 12 throughsome private Internet service provider (ISP) such as, e.g., AmericanOnline. Illustrated in FIG. 1 are multiple ISP “point-of-presence” (POP)systems, each of which includes an ISP POP server 16 linked to a groupof client machines 10 for providing access to the Internet. Each POPserver 16 is connected to a section of the ISP POP local area network(LAN) that contains the user-to-internet traffic. The ISP POP server 16can capture URL page requests from individual client machines 10 for usein user profiling (if user profiling is based on Web surfing habits ofusers) and also to distribute targeted content to users. FIG. 1 alsodepicts a master server 18. In one embodiment, this master server 18 canbe a server that is used to gather and store purchase information thatis parsed from HTML Web pages.

As is well known, the World Wide Web is the Internet's multimediainformation retrieval system. In particular, it is a collection ofservers of the Internet that use the Hypertext Transfer Protocol (HTTP),which provides users access to files (which can be in different formatssuch as text, graphics, images, sound, video, etc.) using, e.g., astandard page description language known as Hypertext Markup Language(HTML). HTML provides basic document formatting and allows developers tospecify links to other servers and files. These links include“hyperlinks,” which are text phrases or graphic objects that conceal theaddress of a site on the Web.

A user of a client machine 10 having an HTML-compatible browser (e.g.,Netscape Navigator) can retrieve a Web page (namely, an HTML formatteddocument) of a Web site by specifying a link via the URL (e.g., www dotyahoo dot com slash photography). Upon such specification, the clientmachine 10 makes a transmission control protocol/Internet protocol(TCP/IP) request to the server identified in the link and receives theWeb page in return.

In one embodiment, the data collection component that detects thepurchase information can be a sniffer 22 that monitors clientinteractions with the WWW. Once purchase information is detected, aparser 24 can be used to parse purchase information from an HTML Webpage. The sniffer 22 and parser 24 can exist within the client machine10, the ISP P.O.P. Server 16, or within the master server 18.

In the embodiment depicted in FIG. 1, the sniffer 22 and parser 24 existwithin the ISP P.O.P. Server 16. FIG. 1 depicts a sniffer 22 and parser24 in one of the ISP servers 16, although a sniffer 22 and parser 24could exist within each ISP server 16. In this embodiment, the sniffer22 accesses the HTML Web pages in transit to or from the client machine10, and the parser 24 parses purchase data from those Web pages. Todetect purchase information, the sniffer 22 looks for any secure Webpages that contain purchase information. The purchase information isfound by using keyword searches or text searches of secure Web pages tofind any of a plurality of keywords or data strings, as described below,that are known purchase keywords or that fit certain requirements. Inthis manner, the sniffer 22 and parser 24 need not know the specific URLinformation for Web pages to be parsed. Instead, the Web pages withpurchase information are located by keyword searches of all secure Webpages, thus allowing the method and system to parse without searchingfor specific URL information that might change over time.

Purchase data that is parsed at the ISP P.O.P. Server 16 can then bedelivered to master server 18 for storage and for use in developingprofiles for users. This sniffer 22 may generally detect and store theuser's program or URL requests and detect if purchase information ispresent, and the parser 24 can store the user's purchase information.Because multiple clients 10 may be connected to the ISP server 16 inthis embodiment, the user's IP address may be stored in a correlationdatabase. Because IP addresses are typically assigned dynamically, theyare not necessarily the same every time a client 10 logs into the ISP.To correlate an IP address with the associated client 10, the datacollection component queries an IP address to an anonymous user ID (AID)cross-reference table stored in another database at the ISP server 16.It then stores the User ID and URL/program information in thecorrelation database.

If the sniffer 22 and parser 24 exist within the client machine 10,which is also shown in FIG. 1 for one of the clients 10, the sniffer 22and parser 24 can extract purchase information as it comes into theclient machine 10 or as it exits the client machine 10. In general, thesniffer 22 and parser 24 can function at the client level in the samemanner as if the sniffer 22 and parser 24 exist at the server level. Ifthe sniffer 22 and parser 24 exist at the client level, the parser 24may periodically send back to the master server 18 parsed information.In still other embodiments, the sniffer 22 and parser 24 exist at boththe client level and at the server level.

In still other embodiments, the sniffer 22 and parser 24 exist withinthe master server 18. It should be noted that in this embodiment, thesniffer 22 might need access to passwords of the user in order to accessHTML Web pages containing purchase information so that parsing ofpurchase information can be accomplished. The sniffer 22 and parser 24can, in this embodiment, function in a manner similar to that if thesniffer 22 and parser 24 exist within the ISP server 16.

In order to detect Web pages containing purchase information, thesniffer 22 can monitor interactions and search for purchase data andkeywords that indicate the presence of purchase information. In otherembodiments, the sniffer 22 may monitor URL information and search forkeywords in the URL information that indicates that a Web page containspurchase data. If the Web pages do contain such purchase information,parsing can be accomplished. Regardless of the location of the sniffer22 and the parser 24, the parser 24 can parse purchase information fromHTML Web pages in the manner described above and in more detail below.

HTML defines the structure and layout of a Web page by using a varietyof tags and attributes. The structure of an HTML page, for instance,begins with “<HTML><HEAD>(header information)</HEAD><BODY>” and endswith “</BODY></HTML>.” The information that appears in the Web page fitsbetween the <BODY> and </BODY> tags. HTML uses a large variety of tagsto specify information about the Web Page. The tag “<B>” starts makingtext in the Web page bold, and the tag “</B>” stops making the textbold. Similarly, the tag “<I>” begins making text appear in italics, andthe tag “</I>” stops making the text appear in italics. Generally, a<TAG> tells the HTML browser to do something, and an attribute goesbetween two tags to tell the HTML browser how to do something. The tag <BR> tells the HTML browser to start a new line.

A number of special characters are also used in HTML syntax for specificinstructions to the HTML browser. These special instructions begin withan “&” and end with a “;”, with the letters between the “&” and the “;”acting as an abbreviation for the instructions. The special character“&nbsp”, for instance, indicates a non-breaking space in the text, andthe special character “&quot;” indicates a quotation mark (“). Thereare, of course, many tags, special characters, and other informationthat make up the HTML language, and the examples above are just a fewexamples of the HTML syntax. Some tags indicate the alignment of text ona Web page others indicate the color of the Web page.

The method and system leverage the fact that any text that appears on aWeb page exists between a right bracket “>” and a left bracket “<” inHTML. Information about the structure of the page appears between a leftbracket “<” and a right bracket “>”. As an example, HTML language for atypical Web page could be:

-   -   <td colspan=2 align=right nowrap valign=top><b>Company:</b>        The first part of this syntax, “<td colspan=2 align=right nowrap        valign=top>”, is HTML syntax that describes the structure of a        section of the page, such as alignment information. This first        part starts with a left bracket “<” and ends with a right        bracket “>”. The second part of the example, “<b>Company:</b>”,        contains text that will appear on the Web page in boldface type.        The actual text, “Company:”, occurs between a right bracket “>”        and a left bracket “<” in the HTML syntax; e.g., “>Company:<”.

Because all of the keywords associated with a purchase and all of theinformation related to a purchase appear as text on a confirmation pageof an on-line purchase, the method and system begin by looking at alltext strings occurring between a right bracket “>” and a left bracket“<” as potential pieces of purchase information.

HTML syntax uses certain tags to separate data in tables. For instance,the “<BR>” tag is used for line breaks, the “<P>” tag is used to start aparagraph, and the “<TD>” tag is used to separate data in a table. Rowsof data in a table are indicated by the “<TR>” tag. Other tags are usedto denote aesthetic changes to the typeface that can be used foremphasis. For example, such tags can include “<B>” for bold face, “<1>”for italics, and “<U>” for underlining.

To increase efficiency during parsing, aesthetic tags, such as <B>, <I>,and <U> can first be removed. Removing such strings increases the chancethat the remaining text is potentially of interest.

A second piece of knowledge used by the method and system relates to thestructure of purchase information. Purchase information can be brokeninto two types of data: product information and transaction information.Throughout this specification, the term “product information” will beused to refer to all information related to a product, such as theproduct name, description, item number, quantity, unit price, and totalprice. The term “transaction information” will be used to refer to anyinformation that is not specifically related to an individual product,but is instead related to the overall purchase or multiple productpurchases. For example, transaction information for a transaction caninclude subtotal, tax, shipping cost, and total cost information, aswell as discount information, shipping type, and credit card type. Thetransaction information for subtotal, tax, shipping cost, discounts, andtotal cost are called transaction prices, and the transactioninformation for shipping type and credit card type are calledtransaction types.

A further piece of structural knowledge that can be useful is thatproduct information is frequently in a table format within a Web page,and transaction information may or may not be in a table. Furthermore,product information usually occurs before transaction information, withthe exception of credit card and shipping type information. In addition,the order total for a purchase is usually the last piece of transactioninformation in an HTML Web page other than the credit card type.

In one embodiment, to detect the presence of data in a table format, onecould look for <TABLE>, </TABLE> tags in the HTML. Some Web pages,however, have different structures with tables embedded in tables thatcan lead to errors if data in table format is detected using the HTMLtags for tables. The method and system, therefore, relies on otherinformation to determine the presence of product and transactioninformation. In particular, in one embodiment, product and transactionkeywords are used to determine whether or not a product or transactiontable is present.

There are certain “keywords” that are commonly used on confirmation andcheckout pages of Web sites for certain types of information. The term“keyword” will be used throughout this specification to refer to a knownword that is commonly used on a Web page to indicate the presence of acertain type of data. Certain keywords are known for product informationand certain keywords are known for transaction information. Keywordtypes are a general category of keywords that fall within the sameclassification. For example, the keyword type “Quantity” could beindicated by one of the following keywords: Quantity, Qty, QTY,Quantity, and quantity. Some common keywords types for productinformation are depicted in Table 1 below. Each keyword has one or morecorresponding descriptors that define the product that the consumerbuys. For instance, a product keyword can be “Description,” and acorresponding descriptor for this keyword can be “Winter Jacket,” whichis a text string of data. These pieces of data that are not keywords,but are instead data that specify information about the product, and arereferred to as “descriptors” throughout this specification. Eachdescriptor is of the same data type as the corresponding keyword. Forinstance, in Table 1 below, the data type for the keyword “Description”is a text string. Table 1 below indicates common product keywords anddata types.

TABLE 1 Product Keywords Keyword Types Data Type Product Name TextDescription Text Item Number Integer Unit Price Real number QuantityInteger Total Price Real number

FIG. 3 is a more detailed list of product keywords. In FIG. 3, eachkeyword in the left-hand column that is of the same keyword type has thesame number in the right-hand column. For instance, the ProductName,Name, ItemName, itemname, Product, SUMMARY, and Title/Author each haveproduct keyword type “1,” indicating that they are of the same keywordtype.

Keyword types for transaction information are depicted in Table 2 below.Again, each transaction keyword type has one or more correspondingdescriptors that define the transaction. For instance, a transactionkeyword can be “Subtotal,” and a corresponding descriptor for thiskeyword can be “$33.99,” which is a real number. Table 2 below indicatescommon transaction keyword types and data types.

TABLE 2 Transaction Keywords Keyword Type Data Type Product Total Realnumber Subtotal Real number Tax Real number Discounts Real number TotalReal number Shipping Type Text Shipping Cost Real number Credit CardType Text Other Any data type

FIG. 4 is a more detailed list of transaction keywords. In FIG. 4, eachkeyword in the left-hand column that is of the same keyword type has thesame number in the right-hand column. For instance, the ProductTotal:,OrderSubtotal, ProductSubtotal, Subtotal:, Subtotal, SUBTOTAL, SubTotal,and subtotal each have transaction keyword type “11,” indicating thatthey are of the same keyword type.

First Embodiment

FIG. 2 depicts a flow diagram of the method in a first embodiment.Instructions to perform the method depicted in FIG. 2 and describedthroughout this specification can exist within the sniffer 22 and parser24, which can be located on the client machine 10, the ISP server 16, orthe master server 18.

Block 100 depicts the parsing of strings of text from HTML syntax andchecking to determine if each string is a keyword. If a string is aproduct keyword, the method continues to look for other product keywordsand keeps track of how many consecutive product keywords are found.Product information in a table is typically indicated by the presence offour or more product keywords in a row. If there are four or moreproduct keywords in a row, therefore, product information arranged in atable has been found. If four or more consecutive product keywords arenot found, then product information in the form of a table has not beenfound. Block 102 of FIG. 2 indicates the determination of whetherproduct information is in table form or not.

After four or more consecutive product keywords have been found, block104 in FIG. 2 is performed. In block 104, the product keywords arestored. Table 4 below illustrates one method that can be used to storethe product keywords. In Table 4, which will be described in greaterdetail below, the product keywords form the first row in a table thatcan be saved to store the product information. Each product keyword inTable 4 forms a column header. Table 4, for instance, has five columnheaders (keywords): Product Name, Description, Item Number, Unit Price,and Quantity.

In block 106 of FIG. 2, the first data string that is not a productkeyword will be the first piece of the first row of product data. Thesepieces of data that are not keywords, but are instead data that specifyinformation about the product, and are referred to as “descriptors,” asnoted above. This piece of data is checked to see if it is the same datatype as the keyword for its column. For example, if the first column(keyword) is “Qty,” or “Quantity,” the data type for quantity is aninteger. The parser 24, therefore, will check the first descriptor toensure that the descriptor is an integer. If the column (keyword) is“Price,” the data string should contain a In addition, a data string for“Price” can be checked, in one embodiment, to ensure that the thirdcharacter from the end is a decimal point. The price “$9.99,” forinstance, contains a decimal as the third from the last character. Themethod, therefore, counts the descriptors as they are found and matchesthem up with the keywords that were found earlier and that form thecolumns of a table in the HTML page. These descriptors are then storedunder the appropriate keyword. Referring again to Table 4, the firstproduct contains the Product Name “Nike T-shirt,” the Description “RedShirt,” the Item Number “134455,” the Unit Price “$22.99,” and theQuantity “1.” This information forms a product row in Table 4.

The method repeats this process of matching descriptors with productkeywords until all of the product information has been parsed from theHTML page, as indicated by block 108 of FIG. 2. All of the productinformation has been parsed when a transaction keyword is found or whena descriptor does not match the column type that it corresponds with. Ifa descriptor does not match the data type for the product keyword (thecolumn type), the information is not in the form of a table, and parsingcan be performed in a different manner.

When parsing descriptors using the inventive method, a differentprocedure can be used from when keywords are parsed. Keywords, even ifmade from multi-word phrases, such as “Order Total,” always occurbetween one right bracket “>” and one left bracket “<”. An example ofthis type of keyword in HTML syntax is “>Order Total:<”. Descriptors, onthe other hand, may extend across several sets of brackets. Forinstance, the descriptor “<b>Nike<b>T-shirt</td>” extends beyond one setof brackets and indicates the term “Nike T-shirt” as a singledescriptor. When potential keywords are parsed, therefore, any datastrings occurring between a right bracket “>” and a left bracket “<”will be taken and appended together to form a single descriptor. Whendescriptors are being parsed, on the other hand, the data strings thatoccur between a right bracket “>” and a left bracket “<” are appendedtogether with any data strings occurring between the next set of right“>” and left brackets “<” until the end of a piece of data is reached,and all of these appended data strings form a single descriptor. The endof a piece of data in HTML is usually indicated by a </td>tag. As anexample, the HTML syntax “<b>Nike<b>T-shirt</td>” is a single descriptorthat contains two data strings between right “>” and left “<” brackets.These data strings are appended together into a single descriptor untilthe “</td>” tag is reached.

The parser 24 therefore fills in the descriptors for each productpurchased in a row under the appropriate column headers (such as inTable 4), which are indicated by the product keywords. When the end of apurchase row is reached, as typically indicated by a “</td>” tag in HTML(to indicate the end of a piece of data) and the last column header(keyword) in a stored table, the next data string could be the firstcolumn of the next product data row or it could be the first transactionkeyword. In this case, the method and system will append all of the datastrings that occur between the first right bracket “>” and first leftbracket “<”, and then check to see if this string is a transactionkeyword. If it is not a transaction keyword, then the method and systemtreats this data string as the first descriptor for a product, and theparser 24 continues to append data strings into the next product datarow until the end of the product row is reached, which is typicallyindicated by the last column header (keyword) in a stored table. Thisprocess is therefore continued until a transaction keyword is reached,which indicates the end of the product information for the purchase.

Table 3 below lists HTML syntax for product information that is in theform of a table:

TABLE 3 Product Information In Table Form <TR><TD bgColor=whitevAlign=top><BR>&nbsp;<B>ProductName:&nbsp;</B></TD><TD><BR>&nbsp;<B>Description:</B></TD><TD><BR>&nbsp;<B>Item: </B></TD><TD><BR>&nbsp;<B>UnitPrice:</B></TD><TD><BR>&nbsp;<B>Quantity:&nbsp;</B> :&nbsp;</B></TD></TR> <TD align=right bgColor=white vAlign=top><BR>&nbsp;<TR><b>Nike<b>T-shirt</td><TD>&nbsp;&nbsp;<BR>&nbsp; <B>RedShirt</B> &nbsp;&nbsp;</td><TD>&nbsp;<B>134455</B>&nbsp;&nbsp;</td><TD>&nbsp;<B> $22.99</B>&nbsp;&nbsp;</TD><TD><BR>&nbsp;<B>1</B>&nbsp;&nbsp;</TD></TR><TR> <TD align=rightbgColor=whitevAlign=top><BR>&nbsp;<B>New Balance X65</B>&nbsp;&nbsp;</td><TD>&nbsp;<B>Running Shoe</B>&nbsp;&nbsp;</td><TD>&nbsp;<B>271721</B>&nbsp;&nbsp;</td><TD>&nbsp;<B>$60.99</B>&nbsp;&nbsp;</TD><TD><BR>&nbsp;<B>1</B>&nbsp;&nbsp;</TD></TR>

In the example of Table 3, the parser 24 recognizes the four or moreproduct keywords that exist consecutively. The parser 34 thereforestores this information, which can be done in the form of a table, suchas Table 4 below. Each product keyword, in this example, is a columnheader in Table 4. When the first data string that is not a productkeyword is located, “Nike,” the parser 24 recognizes that this term isnot a product keyword. This term, however, is appended with thefollowing term, “T-shirt”, until the “</td>” tag is reached, whichindicates the end of a piece of data in the HTML syntax. In thisexample, the term “Nike T-shirt” is recognized to be a descriptorbecause it is not a keyword and because it is of the same data type as“Product Name.” This descriptor is therefore added to a row in Table 4underneath “Product Name” for information regarding a first product.Parsing then continues for the first product, and information is placedin the first product row of Table 4, until the end of the product row inTable 4 is reached (along with the </td> tag in Table 3). This indicatesthe end of a first product data row. The next data string, “New BalanceX65” is then recognized as not being a transaction keyword and insteadas being of the same data type as Product Name. It is therefore added tostorage in a second product data row in Table 4 below. This continuesuntil all of the information for the second, and last, product in Table3 has been parsed and stored.

TABLE 4 Product Information Table Item Product Name Description NumberUnit Price Quantity Nike T-shirt Red Shirt 134455 $22.99 1 New BalanceX65 Running Shoe 271721 $60.99 1

Second Embodiment

If the product keywords are not in the form of a table, a differentprocedure can be followed, as described in the second embodiment thatfollows. Information is not in the form of a table if a first productkeyword is found and the next data string is not recognized as a productkeyword. If this is the case, the first product keyword is stored, asindicated by block 110 of FIG. 2. The next data string is checked todetermine if it is of the same data type as the first product keyword,as indicated in block 112 of FIG. 2. If it is the same data type, thisdata string is appended as a descriptor for the first product keyword,as indicated by block 114 of FIG. 2. The next product keyword is thenfound, and the following data string is checked to determine if it is ofthe same data type as this next product keyword. If it is, this productkeyword and descriptor are stored, as indicated in block 116 of FIG. 2.This process of finding product keywords and associated descriptors isthen repeated until the first transaction keyword is found. A fullerdescription along with an example of parsing keywords and descriptorsfor information that is not in the form of a table is set forth belowfor transaction information (rather than product information).

Once a transaction keyword has been found (block 118 of FIG. 2), thesystem and method continue to look for transaction keywords until astring that is not a transaction keyword is found. If more than oneconsecutive keyword is found, then a table is present. If two or moreconsecutive transaction keywords are not found, then a table oftransaction information is not present. Block 120 of FIG. 2 depicts thisdetermination of whether a table of transaction information is presentor not.

If a transaction data table is present, transaction information isprocessed in the same way as was product information. In other words,the consecutive transaction keywords will be parsed (block 130 of FIG.2), and then the descriptors will be parsed. As indicated by block 132of FIG. 2, the data type of the transaction descriptors can be comparedto the corresponding transaction keyword to ensure that the proper datatype is present. Block 134 indicates that transaction data is parsed andthis process is repeated until the end of the HTML file. In parsing thetransaction descriptors, as in the case of product descriptors, the datastrings that occur between a right bracket “>” and a left bracket “<”are appended with any data strings occurring between the next set ofright “>” and left “<” brackets until the end of a line is reached, asindicated by a “</td>” tag in the HTML syntax and the last column headerin a stored table, such as Table 6 below. When the end of a line (atransaction row) is reached, the next string is either the first columnof the next transaction data row or the end of the HTML page. Typically,transaction information forms only a single data row, because thetransaction information is typically for the entire purchase and is notfor a portion of the purchase, such as one product out of five products.After all of the transaction information is parsed, parsing is complete.Therefore, the system and method stops parsing after it reaches thetotal for the order or after it reaches the end of the file or the“</HTML>” tag.

As an example, the following table, Table 5, shows HTML syntax thatrepresents transaction information that is in the form of a table:

TABLE 5 Transaction Information In Table Form <TD bgColor=whitevAlign=top><BR>&nbsp;<B>Order Subtotal:&nbsp;</B></TD><TD><BR>&nbsp;<B>Shipping:</B><BR>&nbsp;<B>SalesTax:&nbsp;</B></TD><TR><TD align=right bgColor=whitevAlign=top><BR>&nbsp;<B>$53.98</B></TD><TD>&nbsp;&nbsp;<BR>&nbsp;<B>+$5.99</B></TD><TD>&nbsp;&nbsp;<BR>&nbsp;<B>+$0.00</B></TD><TD>&nbsp;&nbsp;</TD></TR>

In this example, the transaction keywords—Order Subtotal, Shipping, andSales Tax—appear consecutively in the HTML syntax, with each beingbetween a right bracket “>” and a left bracket “<”. These transactionkeywords are therefore parsed and, for example, stored in a databasesuch as Table 6 below. The descriptors for each of these transactionkeywords then follows in the HTML syntax in the order of the transactionkeywords. These descriptors are then stored along with the correspondingtransaction keyword. Table 6 below, for instance, shows the completetable with the descriptor for each transaction keyword aligned in thetable with a descriptor below it. When parsing these descriptors, theparser 24 could append all of the data on a line, with the end of theline indicated by the </TD> tag.

TABLE 6 Transaction Information Table Order Subtotal Shipping Sales Tax$53.98 $5.99 $0.00

If more than one consecutive transaction keyword is not found, a tableis not present. If a table is not present, then the next piece of dataafter the first transaction keyword will correspond to a descriptor forthat transaction keyword. Block 122 of FIG. 2 represents the firsttransaction keyword being stored. In block 124, the data type of thenext data string is compared to the data type of the first transactionkeyword, and if the two data types are the same, this descriptor isappended with the transaction keyword (block 126). This process is thenrepeated until the end of the HTML file, as indicated by block 128.

As an example, the following table, Table 7, shows HTML syntax thatrepresents transaction information that is not in the form of a table:

TABLE 7 Transaction Information That Is Not In Table Form <TDALIGN=“RIGHT” BGCOLOR=“003366”><FONT COLOR= “FFFFFF” FACE=“Arial,Helv”SIZE=“2”><B>Product Total:</B><BR> </FONT></TD><TD ALIGN=“right”BGCOLOR=“003366”> <FONT COLOR=“FFFFFF” FACE=“Arial,Helv” SIZE=“3”><B>$64.98</B></FONT></TD><TD ALIGN=“RIGHT” BGCOLOR= “003366”><FONTCOLOR=“FFFFFF” FACE=“Arial,Helv” SIZE=“2”> <B>SalesTax:</B><BR></FONT></TD><TD ALIGN=“right” BGCOLOR=“003366”><FONTCOLOR=“FFFFFF” FACE=“Arial, Helv” SIZE=“3”><B>$3.25</B></FONT></TD>

In this example, a first transaction keyword, “Product Total,” is foundby the parser 24 and recognized as a transaction keyword. The next datastring that is found is “$64.98,” which the parser 24 recognizes as notbeing a transaction keyword. This data string, therefore, is checked todetermine if it is the correct data type for the transaction keyword.Because a number (64.98) is the correct data type for the transactionkeyword (Product Total), the descriptor is recognized as correspondingto the transaction keyword. The transaction keyword is then stored alongwith the descriptor. Table 8 below, for instance, depicts a data tablefor this example. The next data string after “$64.98” is “Sales Tax:”,and this data string is recognized by the parser 24 as being atransaction keyword. The next data string after this transaction keywordis “$3.25,” which the parser 24 recognizes as being the correct datatype for the transaction keyword “Sales Tax:”. This transaction keywordand corresponding descriptor are therefore stored, and a table such asTable 2 below could be produced for this transaction information.

TABLE 8 Transaction Information Table Product Total Sales Tax $64.98$3.25

Third Embodiment

In the examples of parsing product and transaction information notedabove, examples were provided for transaction information and productinformation in HTML syntax in the form of a table and also fortransaction information and product information that was not in the formof a table. It is common for product information to be in table form andfor transaction information to be in either table form or not in tableform. This is commonly the situation because many products may bepurchased in a single transaction, and it is therefore easier in HTMLsyntax to list the product keywords one time and then to list thedescriptors for each product in succession, as described above. Ifproduct information is not in the form of a table, however, the methodand system parse the product information as described above based onproduct keywords and matching of data types.

In one embodiment, certain checking of data is performed when parsingtakes place to determine if the data is accurate. For instance, if onekeyword type is “Total Price,” the “Unit Price” for an item can bemultiplied by the “Quantity” to determine “Total Price” is correct. Thevalue of the descriptor for “Unit Price,” absent the dollar sign, can bemultiplied as a real number by value of the descriptor for the“Quantity.” The integrity of the parser 24 can therefore be dynamicallychecked to determine the accuracy of parsed purchase information.

In another embodiment, product keywords can be contained in imagesinstead of text. In such an embodiment, keyword searching for productkeywords will not be effective. Instead, a different approach can beused. In this approach, the “<TR>” tags are checked to determine if arow is present (a row is indicated by a “<TR>” tag in HTML). The firstrow is therefore found, and each data string in the row (between a“<TR>” tag and a “</TR>” tag) is checked to determine its data type. Thetypical layout of Web pages can then be assumed to attempt to constructthe table of data. After the “</TR>” tag indicates the end of a row, anew “<TR>” tag indicates the presence of another row of data. Based onthe common layouts of confirmation and check-out pages, it can beassumed that a row of data (set off by a “<TR>” tag) is product data ifcertain requirements are met. These requirements are based on the commonlayout of a row of product data. The data strings in a row are thereforechecked against the requirements for product data and, if therequirements are met, the row of data is saved in table form as a row ofproduct data.

The requirements for a row of product data follow. The typical keywordtypes that exist for a row of product data are: Product Name, ProductDescription, Item Number, Quantity, Unit Price, and Total Product Price.The descriptor for the “Product Name” of the product is typically thefirst data string in the row of product data. The first data string cantherefore be assumed to be the product name and can be stored as theproduct name. The second data string is commonly the “ProductDescription,” and hence this data string can be stored as the productdescription. Data strings existing after the descriptor for “ProductDescription” in a row are initially classified as being “other” typedata strings. If there are more than four data strings, including theproduct name and product description, before a data string that appearsto be the quantity or a price, then a data table is not present and adifferent method of parsing can be used.

A data string that is a quantity, or the number of products purchased,is typically the first integer that is less than 99 in value. The firstsuch integer that is less than 99 in a row of data can therefore beassumed to be the quantity. The first data string that is greater than99 is typically the item number, and can therefore be assumed to be theitem number. The first price, as indicated by a data string thatcontains a “$”, is typically the unit price, and can be assumed to bethe unit price. The next price after unit price, as indicated by a datastring that contains a “$”, can, possibly, be the total product price.To determine if this data string is the total product price, this nextdata string is checked to see if it is equal to the quantity multipliedby the unit price. If it is, then this price is assumed to be the totalproduct price. Again, as stated earlier, if more than four data stringsare present before the quantity or a price is found, this method willnot be used and it will be assumed that a table of product data is notpresent. If, however, the row of data meets the requirements for thequantity, item number, unit price, and total product price, and fitswithin the framework described above, the row of data will be saved asproduct data.

The process described above for product data that is in table form butis not set off by product keywords can be repeated for each data row(using the “TR>” and “</TR>” tags) to parse product information. Whenthe first transaction keyword is found, parsing of product informationceases and one of the methods described above for parsing transactioninformation is used.

Fourth Embodiment

In a fourth embodiment that can differ from those described above, themethod and system parse strings of text and check to determine if eachstring fits into one of the types of product information or if it is atransaction keyword. If a string is not a transaction keyword or a datastring related to a transaction keyword, it is treated as a potentialpiece of product information. In this embodiment, product keywords arenot used in parsing. For example, product keywords such as “productname” and “unit price” are not used in parsing product information.Instead, data strings occurring before specific transaction keywords arefound are treated as potential pieces of product information (that is,descriptors for product information), and information about the datastrings are examined to determine what type of information the datastrings represent. This embodiment can have benefits over theembodiments described above because it requires less specific knowledgeabout the layout of a transaction Web page. This embodiment, forinstance, does not use specific product keywords in parsing productinformation. At the same time, this embodiment uses more informationabout the general structure of product information, and this makes it,in some instances, more robust and compact than the other embodimentsdescribed above.

If a data string might be a descriptor for product information, themethod and system determines if the data string contains a monetaryamount. To determine if a monetary amount is present, the data string ischecked for a dollar sign (“$”) and for a decimal point (“.”). Althougha dollar sign ($) is typically present, it is not always included in amonetary amount. If, however, a dollar sign ($) is present, the datastring is determined to be a monetary amount. If a floating point valuewith a decimal point (.) is found without a dollar sign ($), it is stillconsidered to be a potential monetary amount. If a decimal point (.) ispresent and a floating point value is found, the data string is checkedto determine if two decimal places are present after the decimal point(.). If two decimal points are present in a floating point value after adecimal point (.), the data string is considered to be a monetaryamount.

After a monetary amount is found, a determination is made as to whattype of price has been found. Generally, a price for product informationcan be one of the following types of prices: unit price, total price, orcomparative price. A “unit price” is the price for a single unit of theproduct. A “total price” is the unit price multiplied by the number ofthe products purchased. A “comparative price” is the price for a similarproduct by a different manufacturer of the like.

The first price that is found is assumed to be the unit price unlessother information is found to confirm or contradict this assumption. Ifa quantity (that is, the number of units of that product to bepurchased) is known when the first price is found, then the subtotal isassumed to be the first price multiplied by the quantity. If no furtherpricing information is found, then the first price is assumed to be theunit price and the calculated subtotal will be used as the actualsubtotal. A method for determining the quantity is described below.

The second price that is found is assumed to be a comparative priceunless one of two assumptions hold. If the second price is equal to thefirst price multiplied by the quantity, then the second price is thetotal price and the first price is the unit price. If the first price isequal to the quantity multiplied by the second price, then the secondprice is the unit price and the first price is the total price. Ifneither of these conditions applies, then the lesser of the two pricesis assumed to be the unit price and the greater of the two prices isassumed to be the comparative price. These assumptions apply unless athird price is found as described below.

Another set of assumptions applies if a third price is found. If thethird price is equal to the second price multiplied by the quantity,then the second price is the unit price, the third price is the totalprice, and the first price is the comparative price. If the third priceis equal to the first price multiplied by the quantity, then the firstprice is the unit price, the third price is the total price, and thesecond price is the comparative price. If neither of these conditions ismet, then the third priced is ignored. Generally, if one of theconditions above does not apply, the third priced is an unnecessarypiece of information.

The quantity of the product has been mentioned above in the discussionof how to determine which prices belong to different types of prices. Inorder to determine which data string or number is the quantity, certaintests can be performed. Generally, the quantity is expressed as aninteger. There are, however, other types of product information that canalso be integer values, such as the product size and an item code.Generally, a quantity has four digits or less, and an item code has ninedigits or more. A quantity is therefore relatively easily distinguishedfrom an item code. The size of a product, however, can have a similarnumber of digits as the quantity. Generally, therefore, the firstinteger can be assumed to be the quantity and the second integer can beassumed to be the size, and then these assumptions can be tested withpricing information. If the assumption of the first integer of thequantity results in pricing information that makes sense (that is, thequantity multiplied by the unit price equals the total price), then thefirst integer is the quantity. Similarly, if the second integer as thequantity results in pricing information that makes sense, then thesecond integer is the quantity rather than the first integer. Whicheverof the first integer or the second integer does not make sense with thepricing information is assumed to be the product size.

Aside from prices, item codes, quantities, and sizes, non-numericstrings can also be dealt with in parsing product information. In thisembodiment, the first non-numeric string is initially assumed to be theproduct name. The second non-numeric string is initially assumed to bethe product description. If there is a third non-numeric string, thenthe first and second non-numeric strings are checked to determine ifeither string is too short to be informative. In one embodiment, aproduct name and a product description are over three characters inlength. In this embodiment, therefore, if either of the first string orthe second string are three characters or less in length, then the thirdstring replaces the string that is not long enough. As an example, ifthe first string is five characters, the second string is threecharacters, and the third string is six characters, then the thirdstring will replace the second string as the product description. Ifboth of the first and second strings are three characters or less, thenthe third string replaces the first string as the product name.

Product information (that is, the descriptors for product information)for one product can be parsed from an HTML page and inserted into atable, spreadsheet, or other format in a file so that the type ofproduct information is readily discernable. For instance, parsed productinformation for two different products could appear in the form of Table4 in a file. After a complete set of product information has been foundfor a given product, information regarding the next product purchasedcan be searched for and parsed. Generally, the end of a complete set ofproduct information is indicated by the presence of a total price forthe product. In some embodiments, however, the end of productinformation for one product (or the end of one row of productinformation) is indicated by the detection of the product name,quantity, and total price. In this embodiment, all other productinformation for the product, such as the product description andcomparative price, occur in between the product name, quantity, andtotal price. For example, the description for a product typically occursafter the product name, but before the total price. In addition, thecomparative price typically occurs before the total price. Because thecomparative price and description are surrounded by two or more of theproduct name, quantity, and total price, the end of product informationfor one product can be assumed by the detection of the product name,quantity, and total price. In situations where the total price is notfound, but is instead calculated as the quantity multiplied by the unitprice, the detection of the product name, quantity, and total pricestill indicates the end of product information for one product becausethe total price can be calculated only after the unit price and quantityhave been found.

After a complete set of information for one product has been found,product information for the next product can be found using the samemethod described above. In other words, variables for the first price,second price, and so forth are reset and searching begins for the nextproduct. Products are therefore found as indicated above and productinformation can be parsed for each such product. This process of findingand parsing product information is continued until a transaction keywordthat indicates the presence of a subtotal for the entire purchase isfound. In this embodiment, when such a subtotal is found, parsing ofproduct information is complete and transaction information can then beparsed. In some embodiments, some types of transaction keywords, such asthe credit card type and shipping information, can occur before productinformation or in other locations in a Web page. The subtotal for theentire purchase, on the other hand, typically occurs after all of theproduct information, and the subtotal is typically the first transactionkeyword to appear after the product information. For these reasons, thedetection of the subtotal for the entire purchase can be used todetermine the end of product information and the beginning oftransaction information.

To parse transaction information in this embodiment, the system andmethod search for transaction keywords and keep track of how many suchtransaction keywords are found in a row. If four or more transactionkeywords in a row are found, then transaction information arranged in atable has been found. If four or more transaction keywords in a row arefound, then the first data string that is not a transaction keyword isthe first piece of data for the first row of transaction data, thesecond data string is the second piece of data for the first row oftransaction data, and so forth. This process is repeated until all ofthe transaction information has been parsed. All of the transactioninformation has been parsed when either a transaction total or a datastring that does not match its column type (that is keyword type) hasbeen found. Table 5 shows transaction information that is in table form.

If not enough transaction keywords in a row are found, then thetransaction information is not in the form of a table. In such a case,the data string immediately after each transaction keyword is assumed tobe the value for that keyword, and such data strings are parsed intoappropriate locations as such. Table 7 shows transaction informationthat is not in table form.

Generally, there are two types of transaction keywords: prices andtypes. The transaction prices are the subtotal, tax, discounts,shipping, and total. The transaction types are credit card type andshipping type. To find the keywords for the transaction prices,substring matches can be used. This keeps the number of transactionkeywords somewhat small. For example, the keyword “total” can be used tosearch for both the subtotal and the total for the transaction. Becausethe subtotal typically is the first piece of information in thetransaction section, the subtotal can be distinguished from the total byassuming that the first data string having “total” is the subtotal. Anexact match between the keyword for a transaction price and a datastring is therefore not always needed.

For transaction types, an exact match between a keyword and a datastring is typically required to find the descriptive words for thetransaction type. For example, a transaction involving an AmericanExpress card would be detected if there was a data string that matchesone of the following keywords: “American Express,” “AMEX,” and “AX.”Unlike transaction prices, which typically occur only after productinformation, transaction types can occur at any location on a page.

In this embodiment of the invention, two types of transaction keywordfiles can be used. The first file, which can be used for transactionprice keywords, can contain keyword strings followed by a numberrepresenting the keyword type. For example, “tax” keywords can be type12, so that an entry in the first file could be: “Tax 12.” The secondfile, which can be for transaction type keywords, can be slightlydifferent. Each line in the second file contains a keyword stringfollowed by a descriptor and then a number. The description can be usedto provide consistency between keywords that are the same type. Forinstance, “American Express” can be written in one string in this file,followed by the descriptor “AMEX,” and then followed by the keyword type“17.”

While the present invention has been described with reference to severalembodiments thereof, those skilled in the art will recognize variouschanges that may be made without departing from the spirit and scope ofthe claimed invention. Accordingly, the invention is not limited to whatis shown in the drawings and described in the specification, but only asindicated in the appended claims.

1. A method for parsing purchase information from code of a Web page fora purchase, comprising: performing when a sufficient number of productkeywords are present to represent a table of product information, thesteps of: parsing the product keywords end placing the product keywordsas headings for a table of product information; parsing and pastingdescriptive information for each product in a row under the headings inthe table of product information after checking data types to ensurethat each descriptor fits with the product keyword; detecting at leastone known transaction keyword and at least one transaction data stringfollowing that transaction keyword and being associated with thattransaction keyword, the transaction data string being a descriptor forthe transaction keyword; and copying and placing the purchaseinformation into an organized form.
 2. The method of claim 1, wherein afirst data string that is not a product keyword will be a fitst piece ofdescriptive information for the product row.
 3. The method of claim 1,wherein an end of the row for each product is determined by identifyingan indicator in the code.
 4. The method of claim 1, wherein the productkeywords are product keywords matched from a plurality of productkeywords of a common keyword type.
 5. The method of claim 4, wherein thekeyword types include one or more of a product name, productdescription, item number, unit price, quantity, and total price.
 6. Themethod of claim 1, wherein the transaction keywords are organized intogroups of transaction keywords of common transaction keyword types. 7.The method of claim 6, wherein the common transaction keyword typesinclude one or more of a product total, subtotal, tax, discount, total,shipping type, shipping cost, and credit card type.
 8. The method ofclaim 1, wherein detecting at least one known transaction keywordincludes: performing when a sufficient number of transaction keywordsare present to represent a table of transaction information, the stepsof: parsing the transaction keywords and placing the transactionkeywords as headings for a table of transaction information; and parsingdescriptive information for each product in a row under the headings inthe table of transaction information after checking data types to ensurethat each descriptor fits with the transaction keyword.
 9. A method forparsing purchase information from code of a Web page for a purchase,comprising: detecting at least one known product keyword and at leastone product data string following hat product keyword and beingassociated with that product keyword, the product data string being adescriptor for the product keyword for one product in the purchase;performing when a sufficient number of transaction keywords are presentto represent a table of transaction information, the steps of: parsingthe transaction keywords and placing the transaction keywords asheadings for a table of transaction information; parsing descriptiveinformation in a row under the headings in the table of transactioninformation after checking data types to ensure that each descriptor isan appropriate data type for the transaction keyword; and copying andplacing the purchase information into an organized form.
 10. The methodof claim 9, wherein the known product keyword is one product keywordmatched from a plurality of product keywords of a common keyword type.11. The method of claim 10, wherein the keyword types include one ormore of a product name, product description, item number, unit price,quantity, and total price.
 12. The method of claim 9, wherein thetransaction keywords are organized into groups of transaction keywordsof common transaction keyword types.
 13. The method of claim 12, whereinthe common transaction keyword types include one or more of a producttotal, subtotal, tax, discount, total, shipping type, shipping cost, andcredit card type.
 14. The method of claim 9, further comprising checkingeach product data string to determine it the product data string is anappropriate data type for the associated product keyword.
 15. A methodfor parsing purchase information from code of a Web page for a purchase,comprising: locating product information for each product purchased byreviewing data string occurring before a first transaction keyword;locating product information for each product including: performing wheneach data string is pricing information, the steps of: (a) determinigwhich type of pricing information is present; determining a quanity forthe product; (b) determining non-numeric information for the product,the non-numeric information including at least the product name; and (c)determining an end of the product information for each product; locatingtransaction information for the purchase by searching for transactionkeywords from the data string; and copying and placing the locatedproduct information and transaction information into an organized form,wherein determining which type of pricing information is presentincludes: initially assuming that a first price found is the unit price;initially assuming that a second price found is the comparative priceunless: the second price equals the first price multiplied by a quantityof the product, in which case the second price is the total price andthe first price is the unit price; or the first price is equal to thesecond price multiplied by the quantity of the product, in which casethe second price is the unit price and the first price is the totalprice; and if a third price is found, then the third price is the totalprice if: the third price is equal to the second price multiplied by thequantity, in which case the second price is the unit price; or the thirdprice is equal to tile first price multiplied by the quantity; in whichcase the first price is the unit price.
 16. A method for parsingpurchase information from code of a Web page for a purchase, comprising:locating product information for each product purchased by reviewingdata strings occurring before a first transaction keyword; locatingproduct information for each product including: performing when eachdata string is pricing information, the steps of: (a) determining whichtype of pricing information is present; determining a quantity for theproduct; (b) determining non-numeric information for the product, thenon-numeric information including at least the product name; and (c)determining an end of the product information for each product; locatingtransaction information for the purchase by searching for transactionkeywords from the data strings; and copying and placing the locatedproduct information and transaction information into an organized form,wherein the non-numeric information includes one or more of the productname and product description, and wherein determining non-numericinformation for the product includes; initially assuming that a firstnon-numeric data string is the product name; initially assuming that asecond non-numeric data string is the product description; and if athird non-numeric data string is present and if one of the firstnon-numeric data string and the second non-numeric data string is tooshort to be informative, replacing the first non-numeric data string orthe second non-numeric data string with the third non-numeric string asthe product name or product description.